In developing a graphical user interface (GUI) in an object-oriented environments, various methods have been developed for implementing controls. In U.S. Pat. No. 5,555,365, a table is created which specifies the relationship between graphical user interface (hereinafter, GUI) objects and the application object. In the alternative, a programmer can write all of the code for each control on each window to display, format, validate, save data and manage control relationships. Such an approach is inefficient from the perspectives of programmer time, space and operating time, particularly in light of the fact that many of the controls could be “re-used” for different applications.
C++ programmers subclass a set of classes that represent controls included with a compiler or GUI development toolkit or framework. Subclassing the set of provided control classes for specialized purposes is the standard practice for creating specialized controls in an object-oriented graphical environment. For example, a programmer would create a subclass of a list box which reads/writes data from/to a database; create another subclass of the list box which reads/writes its data to/from a table, etc. In this example, if a list box is needed which reads data from a table, then writes the selected entry to a database, a fourth subclass must be written. Additionally, the window code has to be written to manage any relationships between this fourth list box and the other controls on the window. For example, if the user selects the entry “April” out of a list of months, another control on the screen which displays the number of days in the month must be changed to “30”.
The subclassing method has two significant disadvantages: (1) in a large application, the number of subclasses can become very large requiring long development time and a significant amount of code which must be written to manage the relationships between controls; and, subclassing controls prohibits the use of some test tools. Subclassing can also lead to a large number of classes being subclassed from the same control resulting in fewer classes having mix and match capabilities. While some programs provide controls that are “completely functional”, in terms of the class doing everything needed without additional coding, those controls are rarely acceptable for every programming assignment, and are not directly customizable.
What is desirable is a system and method whereby one can leave controls in their respective native class, yet use a set of building blocks to add functionality to the controls, thereby building a GUI application in less time than it would take to write special code for each control function. Using such an inventive system and method, the programmer can develop a set of reusable tools specifically geared toward the special needs of a given application. Existing controls, whether native or enhanced by a compiler vendor or by a third party, could participate in the design as well.